Diseña un proceso como un grafo de nodos —tareas, decisiones, integraciones, esperas— y Orquestador Procesos lo ejecuta paso a paso, manteniendo trazabilidad y reaccionando a los fallos según las reglas que declaras en el propio diagrama.
Orquestador Procesos los convierte en flujos ejecutables, coordinados y auditables.
Trabajo que hoy va por correo, Excel o scripts sueltos, ejecutado de forma fiable y repetible.
CRMs, ERPs y APIs SaaS orquestados sin código pegamento entre ellos.
Una firma, un pago confirmado, un evento IoT — el flujo se reanuda solo cuando llega.
Cada paso queda registrado con quién, cuándo y por qué. Trazabilidad completa.
Reintentos automáticos, conectores de excepción y TTL — sin perder trabajo.
Del diseño que dibujas en Studio a cada paso concreto que el motor ejecuta y registra.
El proceso que dibujas: nodos, conectores, propiedades. Sin estado de ejecución. Versionado e inmutable al publicar.
Una ejecución concreta de una versión. Tiene contexto, estado y tiempos. Miles pueden correr a la vez, independientes.
El cursor que avanza por el grafo. Se divide en un fork paralelo y se reúne en un join. Su estado agrega el de la instancia.
La ejecución de un nodo por un token, con inputs, outputs y tiempos. Lo que ves en el viewer al inspeccionar una instancia.
Un modelo propio, más simple que BPMN 2.0 y a la vez más explícito en errores y tiempos.
Arranca la instancia. Se ejecuta una sola vez.
Tarea humana. Crea una entrada en la bandeja y espera a que alguien la complete.
Integración externa (HTTP/JDBC/FTP/SaaS). Delega en el crawler.
Espera un evento del mundo real o un tiempo concreto.
Decisión, fork o join. Evalúa condiciones y ramifica el token.
Ejecuta una expresión inline para transformar variables del contexto.
Itera sobre una colección hasta agotarla.
Marca un final y cierra el token.
Cuando algo falla, el estado queda registrado y el motor busca la rama de recuperación que declaraste. Nada se pierde.
Por defecto: se sigue cuando el nodo termina con éxito.
Excepción no controlada o estado ERROR. El nodo queda handled y el token continúa por esta rama.
Solo para action: se alcanzó el máximo de intentos. Envía, por ejemplo, a una cola de revisión humana.
Para wait y action: caducó el TTL del nodo y el flujo toma una ruta alternativa.
Si lo modelas, el flujo se recupera solo. Si no, el token queda en error esperando intervención manual — y el operador siempre puede reintentar desde Studio cualquier nodo. Una red de seguridad (DLQ) recoge lo que ni siquiera es interpretable.
El TTL no es un timeout para matar trabajos largos: es la forma de escapar de esperas que se fueron al limbo. Al caducar, el motor cancela el trabajo en vuelo automáticamente.
expires_at = now + 120s.CANCELLED y deja de reintentarse.expired si existe; si no, queda en TTL_EXPIRED.// el TTL cuenta tiempo de pared; max_attempts cuenta intentos. Son independientes y se combinan.
Aislamiento de fallos, escalado independiente y el lenguaje adecuado a cada problema. Si el componente que llama a un ERP cae, el motor sigue y los trabajos se reintentan al volver.
Ejecuta procesos: recibe eventos, mueve tokens, decide ramas y persiste estado.
Definiciones versionadas. Multi-tenant. Solo el engine lee de aquí.
Ejecuta integraciones externas (HTTP/JDBC/FTP) bajo demanda del engine.
Diseñar procesos, monitorizar instancias y gestionar tareas, en web.
Despierta tokens dormidos por tiempo (esperas tipo "espera 2 días").
Recibe webhooks externos y los traduce a eventos para el engine.
Estado durable compartido. La verdad del sistema vive aquí.
Entrega de extremo a extremo con handlers idempotentes. Efecto equivalente a exactly-once.
Solo una versión está activa por proceso. Las instancias vivas siguen ejecutando la versión con la que arrancaron — cambiar el grafo en marcha sería una garantía rota.
Autenticación estándar con proveedores de identidad intercambiables, y aislamiento por organización en el repositorio de procesos.
Cada organización solo ve sus procesos, carpetas y datasources. Aislamiento por organization_id.
Amazon Cognito o ZITADEL (autohospedado), según el entorno.
Cada transición de estado queda registrada con tiempos, intentos y errores.
El flujo se diseña en un editor visual sin programar el motor. La integración con un sistema nuevo se modela una vez, y luego se reutiliza.
Arrastra, conecta y configura propiedades. Modela el flujo y las ramas de error sin escribir código.
100% visualDefine un conector YAML (Camel) para cada sistema externo nuevo. Una vez por sistema, no por proceso.
code-light · 1 YAML/sistemaExtiende el engine vía plugins (políticas de error, validación, observación) solo en casos avanzados.
code · casos rarosTe enseñamos Orquestador Procesos con un proceso real de tu negocio — y cómo la consultoría de Wattyo lo lleva a producción.